Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

tests/sqlx/tests/encrypted_domain/property/e2e_oracle.rs (2)

253-257: ⚡ Quick win

Strengthen ob extractor to validate block element types, not only array shape.

At Line 253-257, ob currently accepts any JSON array. This can let malformed ORE terms (e.g., non-string elements) pass this test unintentionally.

Proposed patch

-    let ob = |p: &serde_json::Value| -> Result<serde_json::Value> {
-        p.get("ob")
-            .filter(|v| v.is_array())
-            .cloned()
-            .ok_or_else(|| anyhow::anyhow!("payload missing array `ob`: {p}"))
-    };
+    let ob = |p: &serde_json::Value| -> Result<Vec<String>> {
+        let arr = p
+            .get("ob")
+            .and_then(serde_json::Value::as_array)
+            .ok_or_else(|| anyhow::anyhow!("payload missing array `ob`: {p}"))?;
+        arr.iter()
+            .map(|v| {
+                v.as_str()
+                    .map(str::to_owned)
+                    .ok_or_else(|| anyhow::anyhow!("payload `ob` contains non-string block: {p}"))
+            })
+            .collect()
+    };

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/sqlx/tests/encrypted_domain/property/e2e_oracle.rs` around lines 253 -
257, The `ob` closure at lines 253-257 only validates that the "ob" field is a
JSON array but does not validate the types of elements within that array. To
strengthen this validation, after confirming that the value is an array, add
logic to verify that all elements within the array are of the expected type
(likely strings for ORE block elements). If any element fails type validation,
return an error with a descriptive message indicating which element or type
check failed.

---

262-270: ⚡ Quick win

Avoid panic-prone [0] indexing in assertions; fail with explicit error context instead.

At Line 263 and Line 269, direct indexing can panic if encrypt_store returns an empty vec, which obscures the root cause during CI failures.

Proposed patch

+    let f4_first = f4_payloads
+        .first()
+        .ok_or_else(|| anyhow::anyhow!("no payload returned for float4 encryption"))?;
+    let f8_first = f8_payloads
+        .first()
+        .ok_or_else(|| anyhow::anyhow!("no payload returned for float8 encryption"))?;
+
     assert_eq!(
-        hm(&f4_payloads[0])?,
-        hm(&f8_payloads[0])?,
+        hm(f4_first)?,
+        hm(f8_first)?,
         "float4 and float8 of the same value must share the hm equality term"
     );
     // ORE term: same f64 input => same ORE ciphertext, so ordering is identical.
     assert_eq!(
-        ob(&f4_payloads[0])?,
-        ob(&f8_payloads[0])?,
+        ob(f4_first)?,
+        ob(f8_first)?,
         "float4 and float8 of the same value must share the ob ORE term"
     );

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/sqlx/tests/encrypted_domain/property/e2e_oracle.rs` around lines 262 -
270, The test assertions use unsafe direct indexing with [0] on f4_payloads and
f8_payloads vectors, which will panic if these vectors are empty without
providing any debugging context. Replace the direct indexing [0] accesses with
safer methods like .get(0) or .first() that return Option types, then chain with
.ok_or() or similar error handling to provide explicit, descriptive error
messages when the vectors are unexpectedly empty. Apply this fix to all
instances of f4_payloads[0] and f8_payloads[0] in the assertion blocks to ensure
clear error context if the encryption operations fail to produce results.